Background

Each UTXO (Unspent Transaction Output) in Bitcoin contains a scriptPubKey, which determines the spending conditions for the UTXO. For example, OP_CHECKSIG requires the spender to possess the private key corresponding to the specified address, and OP_CHECKLOCKTIMEVERIFY mandates that the UTXO can only be spent after a specific time. It’s evident that traditional scriptSigs restrict only inputs, not outputs. The Covenant was introduced to solve this issue, aiming to ensure that the transaction spending a UTXO must also meet some constraints, such as requiring a particular $utxo_A$ to be spent only by a transaction $tx$ with hash $h$. The Covenant unlocks more potential for Bitcoin at the application layer. For more details, see OP_CAT: A Big Step towards Bitcoin Contracts, From Vault to General Computing.

All current Covenant solutions require new Opcodes, such as OP_CAT and OP_CTV. These proposals have sparked heated debates within the community, and OP_CAT has already been included in a BIP proposal (BIP 347). However, it appears that a long verification period will still be required.

Until a soft fork enables Covenant on Bitcoin, an emulation scheme is needed. Currently, the most feasible solution seems to be the Committee Presign scheme, which has already been adopted by many projects, such as Bitlayer, BitVM, and Babylon. This article will provide an in-depth analysis of the Committee Presign scheme.

Covenant Emulation Committee

Brief explanation

In this Committee Presign scheme, a Covenant Emulation Committee (CEC for short) composed of $n$ Signers is created. If the covenant needs to restrict the spending of $utxo_A$, the scriptPubKey corresponding to $utxo_A$ must include the signature check of the $n$ Signers in CEC. Besides, as long as CEC only presigns $tx_A$, no other transaction can spend $utxo_A$ except $tx_A$.

Signer

Organizational Form of CEC

There is no restriction on the organizational form of CEC—it can be a chain or DAO—as long as the members stay active. However, considering membership updates, rewards, and punishment, using a chain may be a better choice.

Presign

For each presign instance, CEC members need to follow the steps below:

1. Each Signer generates a new key pair.
2. Using the new key pair, CEC members collaborate to sign the transactions $\{tx_A, tx_B, tx_C, …\}$ that spend UTXOs $\{utxo_A, utxo_B, utxo_C, …\}$.
3. Discard the key pair.
4. Publish the signed transactions $\{tx_A, tx_B, tx_C, …\}$.

Multisignature

Bitcoin script—Traditional Script and Tapscript—supports three methods for multisignature verification, which we will now discuss along with their advantages and disadvantages:

OP_CHECKMULTISIG in Traditional Script

Example:

1
2
3
4
5
// scriptPubKey
OP_2 <PubKey1> <PubKey2> <PubKey3> OP_3 OP_CHECKMULTISIG

// scriptSig (due to a bug in the implementation of OP_CHECKMULTISIG, an OP_0 is required at the beginning of the scriptSig)
OP_0 <Signature1> <Signature2>

The scriptSig requires the order of signatures to match the order of public keys in the scriptPubKey. For example, Signature1 corresponds to PubKey1, and Signature2 corresponds to PubKey2. However, if the scriptSig is changed to OP_0 <Signature2> <Signature1>, it won’t work because OP_CHECKMULTISIG traverses the public key list only once. If a check fails, the next public key is checked for the same signature, until $m$ valid signatures are verified.

• Pros: It’s the only feasible solution within Traditional Script, where each Signer’s signature can be collected directly. If an error occurs during script execution, the faulty Signer can be easily identified.
• Cons: It requires traversing the public key list to verify each signature, which makes both the space and computational complexity $O(n)$. When $n$ is large, it becomes inefficient and costly. Additionally, the maximum number of $n$ supported is 20.

OP_CHECKSIG in Tapscript

Example:

1
2
3
4
5
// scriptPubKey
<AggregatePubKey> OP_CHECKSIG

// scriptSig
<AggregateSignature>

The format of OP_CHECKSIG in Tapscript is the same as in Traditional Script, but Tapscript replaces ECDSA with the more secure Schnorr signature algorithm, which supports aggregation. Therefore, based on the linear homomorphism of Schnorr, multiple Signers can collaborate off-chain to generate aggregate public keys and signatures. This approach not only improves execution efficiency but also reduces costs.

• Pros: Unlike OP_CHECKMULTISIG, it doesn’t require traversing the public key list. The space and computational complexity are $O(1)$, making it more efficient and less costly. Theoretically, there is no limit to the number of Signers.
• Cons: Parties need to collaborate off-chain through an additional communication protocol to generate aggregate public keys and signatures. It only supports n-of-n multisignature and cannot support m-of-n threshold signature.

OP_CHECKSIGADD in Tapscript

Example:

1
2
3
4
5
// scriptPubKey
<PubKey1> OP_CHECKSIG <PubKey2> OP_CHECKSIGADD <PubKey3> OP_CHECKSIGADD OP_2 OP_NUMEQUAL

// scriptSig
<Signature1> <Signature2> <>

OP_CHECKMULTISIG has been deprecated in Tapscript and replaced by OP_CHECKSIGADD, which is equivalent to OP_ROT OP_SWAP OP_CHECKSIG OP_ADD. Unlike OP_CHECKMULTISIG, it requires the number of signatures in the scriptSig to match the number of public keys in the scriptPubKey. For places where no signature exists, an empty vector is used. During execution, if a signature corresponds to an empty vector, verification is skipped. Therefore, a maximum of $m$ verifications will occur, making it more efficient than OP_CHECKMULTISIG.

• Pros: Supports m-of-n threshold signature. Like OP_CHECKMULTISIG, it does not require additional off-chain communication. It supports up to 999 Signers.
• Cons: Does not support public key/signature aggregation. The space complexity is $O(n)$, and the computational complexity is $O(m)$. When $m/n$ is large, efficiency decreases, and costs increase.

n-of-n multisignature in CEC

Bitlayer research team has done a solid analysis of Musig2 application in BitVM. If using n-of-n multisignature, OP_CHECKSIG in Tapscript is the most suitable solution. However, it requires an additional communication protocol among Signers to achieve signature aggregation. Musig2 is a signature aggregation protocol based on Schnorr, requiring two rounds of additional communication. For a detailed explanation, refer to BIP-327 MuSig2 in Four Applications: Inscription, Bitcoin Restaking, BitVM Co-sign, and Digital Asset Custody. Here, we focus on how the Musig2-based multisignature protocol integrates with CEC.

Workflow of n-of-n multisignature for CEC

1. The Covenant Requester broadcasts UTXOs to ensure all Signers receive the information.
2. Each Signer validates the UTXO, checking the following:
   • The scriptPubKey requires the Committee’s n-of-n multisignature.
   • The remaining parts of the scriptPubKey follow the pre-defined rules.

   Upon successful validation, each Signer constructs the transactions corresponding to the UTXOs according to the predefined rules, signs the transactions with its key, and starts the Musig2 instance.

3. After the instance completes, the transactions and corresponding aggregate signatures will be published on a public board (the form of the public board is not restricted and can be a chain like Ethereum).
4. The Covenant Requester retrieves the presigned transactions and signatures from the public board.
5. The Covenant Requester verifies the transactions and signatures, specifically checking:
   • The transactions follow pre-defined rules.
   • The signatures are valid.
6. The Covenant Requester submits the transactions to the Bitcoin network.

Security and Liveness

All the following analyses are based on the assumption of a synchronous network.

Security

• If an honest Signer outputs a signature $\sigma$, all other Signers will output the same signature $\sigma$.

  If an honest node outputs the signature $\sigma$, it must have received $n$ partial signatures $\gamma_k$ (including its own). Based on the assumption of a synchronous network, all other Signers will also receive the same $\gamma_k$ within time $\Delta$, and thus, they will all output the signature $\sigma$.

• If at least one Signer is honest, malicious Signers cannot output a valid signature $\sigma’$ for an invalid message $m’$.

  If malicious Signers output a valid signature $\sigma’$ for the message $m’$, they must have received $n$ partial signatures $\gamma_k’$ (including their own), where $\gamma_i’$ comes from an honest node $i$. However, the honest node will not generate a partial signature for the invalid message $m’$, so the assumption does not hold.

• If at least one Signer is honest, the funds will not be misappropriated.

  Since the honest nodes will discard their key pairs after constructing the signature, no transaction other than the presigned one can spend the UTXO, and the UTXO cannot be privately appropriated by the Committee.

In conclusion, the Committee’s security threshold is 1-of-n, which means that as long as there is an honest node in the committee, the security of the system can be guaranteed.

Liveness

To ensure the liveness, all Signers must be online; otherwise, presigning cannot be completed. Therefore, the Committee’s liveness threshold is n-of-n.

Future Directions

Trade-off Between Security and Liveness

From the above analysis, we can see that if even one node is offline or maliciously unresponsive, the Committee will lose its liveness. In some scenarios, to improve liveness, the assumption of the number of offline nodes can be relaxed by lowering the signature threshold, such as adopting an (n-f)-of-n threshold (f represents the number of fault-tolerant nodes). At the same time, to ensure security, there must be at least one honest node online, so the security threshold will degrade from 1-of-n to (f+1)-of-n. Since OP_CHECKSIG in Tapscript doesn’t support threshold signature, lowering the threshold requires OP_CHECKMULTISIG or OP_CHECKSIGADD.

Signer Rotation

If the Committee is, in fact, a contract on another chain, this contract can use POS (Proof of Stake) to decide the Signers. If presigning is not completed within the stipulated time, the signers who fail to sign will be penalized, and membership rotation will take place.

Current State of Committee Presign

Committee Presign is not just a theoretical concept, it has already been adopted by many projects.

• Babylon uses OP_CHECKSIGADD in Tapscript for Committee Presign, generating signatures for a given staking request.

• In Bitvm2’s latest paper, it is explicitly mentioned that before Covenant is implemented, the Committee Presign scheme will be used to simulate Covenant.

• Bitlayer will use Committee Presign as a transitional solution before Covenant is available on the Bitcoin mainnet.

Conclusion

This article analyzes the Committee Presign scheme as an emulation for Covenant, explains three multisignature solutions in Bitcoin, and discusses their pros and cons. It also provides a flowchart of how Musig2 is applied to Bitcoin multisignature. Furthermore, the article explores the potential future forms and developments of the Committee. Until Covenant is fully implemented, the Committee will serve as a core component ensuring system security.

Reference

• BitVM2: Bridging Bitcoin to Second Layers
• BIP-327 MuSig2 in Four Applications: Inscription, Bitcoin Restaking, BitVM Co-sign, and Digital Asset Custody
• OP_CAT: A Big Step towards Bitcoin Contracts, From Vault to General Computing
• Zone Concierge Module